This is a bit awkward with how layer shell currently works, but this seems like the best way to address #29, for now. Along with a change in cosmic-panel.

In addition to showing the dock, we need to make sure the workspace overview doesn't try to draw anything over (or under) it, and that the dock receives pointer input.

• Ideally, for interoperability, the panel and workspace overview would be designed in such a way for this to work with any other panel or workspaces-overview-like shell surface, without explicit communication between the components.
  • It's not obvious how this could work though, so instead the workspaces overview notifies the panel that it is visible through the DBus protocol initially added in Expose DBus protocol with signals indicating when shown/hidden #206.
• The obvious way to do this is to have, given such a protocol, is to have the panel show autohide surfaces and add an exclusive zone when the workspaces overview is shown.
  • This didn't behave well; the problem is that cosmic comp then tries to re-layout tiled workspaces to take into account the exclusive zone, which also appears in workspace capture.
• Instead, cosmic-workspaces can try to use cosmic-overlap-notify-unstable-v1 to see where the panel is, and leave space for it.
  • It's not really possible to know from this which layer-shell namespaces are cosmic-panel, if custom panels happened to be configured. (Though this isn't normally an issue; presumably not many people are going to want to configure more than 2...)
  • It seems like it would require awkward heuristics to convert the surface size and overlap regions into padding on each screen edge.
• So instead, this reads the panel config from cosmic-config. Which seems more reliable than dubious heuristics, although it would be nice to avoid this.
• This still has the issue that the panel and workspaces overview are on Layer::Top, but since the workspaces overview surface is created later, it ends up higher in the z-order, so without an exclusive zone the panel is non-interactive.
  • cosmic-workspaces could set an input region to allow this, but for docks that don't extend to the edges, it would need to be a cut-out of the exact right size, to allow not send input to windows behind the panel and workspace overview. (Or some other surface would need to be created behind it to accept input).
  • Maybe the compositor could special-case the z-order in some way, but it looks like Smithay wouldn't allow that without changes, and that's awkward.
• So instead, when the auto-hide panel is shown in the workspace overview, cosmic-panel temporarily moves it to Layer::Overvlay so it appears above the workspaces overview.

Result: cosmic-workspaces reads cosmic-panel config to add padding for auto-hide panels. Cosmic-panel detects through DBus that the workspaces overview is shown, and shows the dock (without any animation). Cosmic-panel doesn't add an exclusive zone, but does move the dock to Layer::Overlay to make sure it gets input instead of cosmic-workspaces.

In the future, it would be good to to see if we can find a nicer way to handle this sort of thing, perhaps in a future ext-layer-shell protocol. But as long as this version seems to work, it seems like a better be for now than trying to come up with an extension protocol for layer shell to make this possible, or adding multiple awkward special cases to the compositor.

Unlike some alternatives, this solution will also work on other compositors without special protocols, or if we go back to drawing the background in cosmic-workspaces (probably using a subsurface) instead of a special case in the compositor. Though for now (other than with the mock-backend feature) cosmic-workspaces, unlike cosmic-panel, does not attempt to be compatible with any other compositor.

There are a couple things that still need to be addressed, but this seems to be working generally well, unlike my earlier solutions.